syntax: Remove `DummyResult::expr_only`

The effect is that if a built-in macro both returns an erroneous AST fragment and is used in unexpected position, then the incorrect position error won't be reported.

This combination of two errors should be rare and isn't worth an extra field that makes people ask questions in comments.
(There wasn't even a test making sure it worked.)

Addresses rust-lang#63468 (comment)
r? @estebank

Add NodeId for Arm, Field and FieldPat

Extracted from rust-lang#63468

syntax: Remove `DummyResult::expr_only`

The effect is that if a built-in macro both returns an erroneous AST fragment and is used in unexpected position, then the incorrect position error won't be reported.

This combination of two errors should be rare and isn't worth an extra field that makes people ask questions in comments.
(There wasn't even a test making sure it worked.)

Addresses rust-lang#63468 (comment)
r? @estebank

expand: Unimplement `MutVisitor` on `MacroExpander`

Each call to `fully_expand_fragment` is something unique, interesting, and requiring attention.
It represents a "root" of expansion and its use means that something unusual is happening, like eager expansion or expansion performed outside of the primary expansion pass.
So, it shouldn't hide under a generic visitor call.

Also, from all the implemented visitor methods only two were actually used.

cc rust-lang#63468 (comment)

Add NodeId for Arm, Field and FieldPat

Extracted from rust-lang#63468

syntax: Remove `DummyResult::expr_only`

The effect is that if a built-in macro both returns an erroneous AST fragment and is used in unexpected position, then the incorrect position error won't be reported.

This combination of two errors should be rare and isn't worth an extra field that makes people ask questions in comments.
(There wasn't even a test making sure it worked.)

Addresses rust-lang#63468 (comment)
r? @estebank

Resolve attributes in several places

Resolve attributes for Arm, Field, FieldPat, GenericParam, Param, StructField and Variant.

This PR is based on @petrochenkov work located at petrochenkov@83fdb8d.

Rollup of 5 pull requests

Successful merges:

 - #63468 (Resolve attributes in several places)
 - #64121 (Override `StepBy::{try_fold, try_rfold}`)
 - #64278 (check git in bootstrap.py)
 - #64306 (Fix typo in config.toml.example)
 - #64312 (Unify escape usage)

Failed merges:

r? @ghost

feature_gate: Remove dead code from attribute checking

rust-lang#63468 is merged, so all attributes go through name resolution now, so we can remove code that previously performed some checks for attributes not going through resolution.

Fully integrate derive helpers into name resolution

```rust
#[derive(Foo)]
#[foo_helper] // already goes through name resolution
struct S {
    #[foo_helper] // goes through name resolution after this PR
    field: u8
}
```
How name resolution normally works:
- We have an identifier we need to resolve, take its location (in some sense) and look what names are in scope in that location.

How derive helper attributes are "resolved" (before this PR):
- After resolving the derive `Foo` we visit the derive's input (`struct S { ... } `) as a piece of AST and mark attributes textually matching one of the derive's helper attributes (`foo_helper`) as "known", so they never go through name resolution.

This PR changes the rules for derive helpers, so they are not proactively marked as known (which is a big hack ignoring any ambiguities or hygiene), but go through regular name resolution instead.
This change was previously blocked by attributes not being resolved in some positions at all (fixed in #63468).

"Where exactly are derive helpers in scope?" is an interesting question, and I need some feedback from proc macro authors to answer it, see the post below (#64694 (comment)).

Starting from rust-lang#63468 cfg attributes on variants, fields, fn params etc. are processed together with other attributes (via `configure!`).